1. Introduction

L’ingénierie des exigences est d’une importance capitale, surtout en Ingénierie Système. En général les exigences sont exprimées par des ingénieurs dédiés à cette activité. La complexité des systèmes modernes (embarqués, communicants, critiques, …​) rendent cruciale cette analyse.

Joke
Figure 1. 300 corps de métiers sont parfois présents sur un même chantier
Besoins, exigences : question de vocabulaire

La difficulté de l’emploi massif de l’anglais fait qu’il existe souvent une confusion entre les termes anglais et leurs traduction française. Nous précisons donc ici notre utilisation des termes.
Requirements

Exigences, c’est à dire :

une fonction ou une propriété que doit satisfaire le système considéré.
— OMG SysML v1.5, p. 161

Par nature une exigence doit pouvoir être vérifiable.

En génie logiciel on parle plus classiquement des spécifications ("spec") pour parler des contraintes à respecter pour un système.

Les ingénieurs systèmes ont depuis longtemps intégré le terme d’exigences comme traduction directe de requirement.

Besoins

Il s’agit des exigences du client. En UML™ on va plus les retrouver dans les cas d’utilisation. Ils sont à l’origine des requirements tels que définis plus haut.

Il est important pour une exigence qu’elle ne soit pas ambiguë (contrairement au terme "en" dans la consigne exprimée par la maman dans l’illustration ci-dessous : "Ramène moi 1 bouteille de lait. S’il y a des oeufs, ramène m’en 6.").

Joke
Figure 2. Spécification ambiguë (taken from https://plus.google.com/100035762233109552669/posts/a8Hafq2hZ74)

2. Fondements

On abordera :

  • L’organization des Requirements

  • Les Requirements properties

  • Les Requirements links

  • Les Requirements Diagrams

  • Les considérations sur la traçabilité

  • Annotations des Requirements

  • Les Use Case Diagrams

L’ingénierie des exigences est une discipline à part entière et nous n’abordons ici que les aspects en lien avec la modélisation. Voir le livre de référence pour plus de détails ([Sommerville1997]) ou le guide de l’AFIS ([REQ2012]).

Il n’existe pas de diagramme UML™ pour traiter des exigences en particulier. C’est pourquoi ce diagramme a été introduit par SysML™.

3. L’organisation des Requirements

Il ne s’agit pas ici de revenir sur les exigences elles-même, mais plutôt de voir comment SysML™ permet de les exprimer, de les manipuler et surtout de les lier avec le reste du système.

3.1. Représentation de base

Un Requirement en SysML™ n’est qu’un bloc particulier.

Définition : sysml Requirements (OMG SysML v1.5, p. 161)

A requirement specifies a capability or condition that must (or should) be satisfied…​ A requirement is defined as a stereotype of UML Class…​
SysML and UML
Figure 3. Un exemple de _Requirement_ en SysML (source <<SysML>>, p. 159)

3.2. Différents types d’organisation

L’ingénierie des exigences aboutit généralement à une liste organisée d’exigences, que ce soit en terme de fonctionnelles/non fonctionnelles, de prioritaires/secondaires, etc. Le principal support de SysML™ à cette organisation, outre la possibilité de les annoter (cf. section Stéréotyper les exigences), consiste à utiliser les packages.

Plusieurs types d’organisations sont possibles :

  • Par niveau d’abstraction

    • Besoins généraux (en lien avec les use cases par exemple)

    • Besoins techniques (en lien avec les éléments de conception)

  • Par point de vue

    • Besoins principaux (en lien avec les use cases)

    • Besoins spécifiques :

      • Fonctionnels

      • Marketing

      • Environnementaux

      • Business

      • …​

  • etc.

3.3. Tableaux de Requirements

Les requirements sont habituellement stockés dans des tableaux (feuilles excel le plus souvent!). Il est donc recommandé par le norme et possible dans de nombreux outils de représenter les exigences sous forme tabulaire.

Définition : sysml Requirements Table (OMG SysML v1.3, p. 145)

The tabular format is used to represent the requirements, their properties and relationships…​
req table
Figure 4. Exemples tableau d'exigences (OMG SysML v1.3, p. 145)

La plupart des outils modernes permettent le passage entre outils classiques de gestion des exigences (comme DOORS™) et outils de modélisation SysML™ (comme Modelio, illustré ci-dessous).

req modelio
Figure 5. Import Modelio de tableau d'exigences (tiré de <<Modelio2012>>)

4. Les Requirements properties

À partir du moment où on commence à définir des propriétés pour les éxigences, on peut considérer que l’on est à la frontière avec la phase d’analyse des exigences.

Il est possible d’indiquer un certain nombre de propriétés sur un requirement :

  • priority (high, low, …​)

  • source (stakeolder, law, technical, …​)

  • risk (high, low, …​)

  • status (proposed, approved, …​)

  • verification method (analysis, tests, …​)

Dans le cadre du module MPA nous ne retiendrons comme attribut d’un requirement que son identifiant et le texte le désignnat (les deux attributs obligatoire). La priorité sera donné par le client en terme de cycle (on traitera en premier les requirements prioritaires).

Ainsi en plantUML, une exigence ressemblera à ceci (cf. rendu ici):

class ObtenirHoraires <<requirement>> {
	Text = "Le logiciel doit fournir les horaires rapidement."
	Id = "14.2"
	}

5. Les Requirements links

Les principales relations entre requirements sont :

Containment

Pour décrire la décomposition d’une exigence en plusieurs sous-exigences (⊕–). Typiquement dès qu’une exigence est exprimée avec une conjonction "et" ("La voiture doit être rapide et économe.").

Refinement

Pour décrire un ajout de précision (<<refine>>), comme par exemple une précision.

Derivation

Pour indiquer une différence de niveau d’abstraction (<<deriveReqt>>), par exemple entre un système et un de ses sous-systèmes.

Lorsqu’une exigence possède plusieurs cas <<refine>> qui pointent vers lui, on considère que ces différents cas sont des options possibles de raffinement (cf. [conventions]).
req exp1
Figure 6. Exemples de relations entre exigences

Il existe ensuite les relations entre les besoins et les autres éléments de modélisation (les block ou les class principalement) comme <<satisfy>> ou <<verify>>, mais nous les aborderons dans la partie transverse.
topcased req connections
Figure 7. Relations liées aux _requirements_ dans TOPCASED

6. Les Requirements Diagrams

Voici un exemple de req un peu plus étoffé, tiré de la norme (voir aussi Exemples de _rationale_ et _problem_ (tiré de <<SysML>>)) :

hsuv reqs1
Figure 8. Exemples de composition d'exigences (tiré de <<SysML>>)

7. Stéréotyper les Requirements

Tout comme pour n’importe quel bloc, il est possible de stéréotyper les requirements. Ceci permet de se définir ses propres priorités et classifications. Quelques exemples de stéréotypes utiles :

  • <<interfaceRequirement>>, <<physicalRequirement>>, …​

  • <<FunctionalRequirement>>, <<nonFunctionalRequirement>>

8. Annotations des Requirements

Il est possible d’annoter les éléments de modélisation en précisant les raisons (rationale) ou les éventuels problèmes anticipés (problem).

hsuv reqs2
Figure 9. Exemples de _rationale_ et _problem_ (tiré de <<SysML>>)

9. Les considérations sur la traçabilité

Une fois que les requirements ont été définis et organisés, il est utile de les lier au moins aux use cases (en utilisant <<refine>> par exemple) et aux éléments structurels (en utilisant <<satisfy>> par exemple), mais ceci sera abordé dans la partie transverse.

En général chaque requirement devrait être relié à au moins un use case (et vice-versa!).

10. Les Use Case Diagrams

Bien que nous traitions les cas d’utilisation dans la partie comportement, nous les abordons ici du fait de leur proximité avec les requirements.

req uc relation
Figure 10. Exemple de lien entre use case et requirements

Ce diagramme est celui que vous avez appris l’an dernier en UML™.

UCGestionNotes
Figure 11. Exemple de diagramme des cas d'utilisation (`B`)
uc
Figure 12. Autre exemple de diagrammes des cas d'utilisation (`B`)

Un acteur représente un rôle joué par un utilisateur humain. Il faut donc plutôt raisonner sur les rôles que sur les personnes elles-mêmes pour identifier les acteurs.

11. Exigences et tests

11.1. Principes

Pour ce qui ce concerne ce module nous allons nous contenter de maintenir des matrices croisant les exigences d’un côté et les tests de l’autre.

Par exemple :

matriceTraca
Figure 13. Exemple de matrice de traçabilité

Dans la réalité, les entreprises industrialisent le processus de vérification des exigences en utilisant des outils adaptés :

testindus
Figure 14. Le cycle de la qualification fonctionnelle en lien avec les besoins métiers (tirée de [TestsIndustriels2009])

12. Exemple complet

En prenant un exemple tiré de l’exemple du Radio Réveil…​

12.1. Le texte du cahier des charges

Le texte complet de l’exemple ne précise pas le cahier des charges de l’Autoradio (AR), considérant que tout le monde sait ce que c’est!

Rédigeons tout de même quelques extraits (numérotés) de texte possible :

  1. L’AR est un dispositif qui permet d’écouter la radio de manière confortable et interactive.

  2. L’AR doit être capable de mémoriser un certain nombre de station différentes.

  3. L’Utilisateur de l’AR doit pouvoir choisir sa station parmis un choix donné.

  4. L’Utilisateur de l’AR doit pouvoir régler le niveau sonore.

  5. L’Utilisateur de l’AR doit pouvoir chercher une station en "balayant" les ondes FM.

  6. …​

12.2. Expression des exigences

Nous pouvons, en analysant ce cahier des charges, déduire un certain nombre d’exigences. Nous les écrivons ici sous forme tabulaire, puis en utilisant le langage Gherkin.

Concernant Gherkin, pour ceux qui veulent aller plus loin, il est possible d’automatiser la génération des tests à partir de ce genre de langage. C’est ce que fait Cucumber pour Ruby.

Version tabulaire :

tabulaire
Figure 15. Exemple de liste d'exigences (tirée de [TestsIndustriels2009])

Exemple de version textuelle formattée :

#encoding: utf-8
Feature: Scénario simple d'utilisation de l'AutoRadio (AR)
  In order to vérifier que le son marche
  As an utilisateur lambda
  I should be able to exécuter ces scénarios et constater les effets

  Scenario: Augmenter le son
    Given un AR avec le son à 0
    When Je presse le bouton "Volume +"
    Then Le son passe à 1
    And Je commence à entendre la radio

12.3. Plan de test

Créer un plan de test consiste à prévoir l’ensemble des tests à l’avance de manière à prévoir la couverture de ces tests.

plantest
Figure 16. Exemple de plan de test simplifié (tirée de [TestsIndustriels2009])

12.4. Analyse et la conception

Dans un cycle classique ("en V" par exemple), les modèles sont réalisés avant l’implémentation (codage).

AutoRadio UC
AutoRadio DC
AutoRadio DS Suivante

Dans un cycle Agile, chaque cycle possèdera ses modèles, eux aussi versionnés, qui eux aussi évolueront en même temps que le code.

12.5. Lien et traçabilité

Plus encore que dans les méthodes classiques, il conviendra de vérifier que code et modèles sont bien cohérents. On pourra donc :

  • générer les codes à partir des modèles

  • générer les modèles à partir des codes (cf. commentaires)

  • utiliser des outils intégrés comme eclipse

  • avoir un plan systématique de révision code/modèle

  • …​

Exemple de code Java commenté pour la génération automatique de diagrammes plantUML
package demo;

class Controller {}
class EmbeddedAgent {}
class PowerManager {}

/**
 * @extends Controller
 * @extends EmbeddedAgent
 * @navassoc - - 1..* PowerManager
 * @note this is a note
 */
class SetTopController implements URLStreamHandler {
  public String name;

  int authorizationLevel;
  void startUp() {}
  void shutDown() {}
  void connect() {}
}

/** @depend - friend - SetTopController */
class ChannelIterator {}

interface URLStreamHandler {
  void OpenConnection();
  void parseURL();
  void setURL();
  void toExternalForm();
}
doclet
Figure 17. Exemple de diagramme généré par javadoc (tirée de [TestsIndustriels2009])

13. En résumé

Les exigences sont très importantes en ingénierie système, du fait de la multiplication des sous-systèmes et donc des intermédiaires (fournisseurs, sous-traitants, etc.) avec qui les aspects contractuels seront souvent basés sur ces exigences.

Il n’est donc pas étonnant qu’un diagramme et des mécanismes dédiés aient été prévus en SysML™.

Table 1. Déclinaison des Exigences
Exigences Structure Comportement Transverse

Organisation

⊕–, <<deriveReqt>>

Analyse

<<satisfy>>, <<refine>>

<<satisfy>> entre reqs et UC

<<refine>>

Conception

<<allocate>>+

Implémentation

<<satisfy>>, <<verify>>

En terme de démarche, il est classique d’avoir de nombreux aller-retour entre la modélisation des exigences et la modélisation du système lui-même (cf. Exemple de démarche (_SYSMOD Zigzag pattern_) (tirée de [TestsIndustriels2009])).

zigzag
Figure 18. Exemple de démarche (_SYSMOD Zigzag pattern_) (tirée de [TestsIndustriels2009])

14. Pour aller plus loin…​

15. Questions de révision

tuxteacher Questions

Quelles sont les différences entre besoins et exigences ?

Quelles sont les différences entre un backlog de produit et une liste d'exigences?

En quoi les cas d’utilisation sont-ils complémentaires des exigences?